…a=` (#9921)

Follow up on #9920 (but
can be reviewed / merged independently), I'm working on making it easier
to query logs for events, specifically relating to specific parachains.

We also incoherently sometimes use `"para="` and sometimes `"para_id=`",
which also makes Grafana Queries harder to do:

**All queries are done during 1 hour period** (2025-10-03 9:45-10:45
GMT)

## Parachain side:
Query: `{chain="yap-kusama-3392"} |~ "para=""` gives 0 hits
Query: `{chain="yap-kusama-3392"} |~ "para_id=""` gives 12k hits

## Relaychain side:
Query: `{chain="kusama"} |~ "para="` gives 286k hits
Query: `{chain="kusama"} |~ "para_id="` gives 99k hits

# Changes
I've changed so that we always use `para_id=` which is 3 chars longer
but so clearer than `para=` (and with [my
PR](#9920), we saved 4
chars `['I', 'd', '(', ')']`, so this is actually still net -1 char
logged)

All logs seem to come from
[prospective-parachains/src/lib.rs](https://github.com/paritytech/polkadot-sdk/blob/bf235845f9ecb2b84264f255afd7aefdd5ddb603/polkadot/node/core/prospective-parachains/src/lib.rs#L797),
using `para = ?`, which I've now changed to `para_id = ?`

(Grafana (loki) query `{chain="kusama",
subtarget!="prospective-parachains"} |= "para="` yield no results, i.e.
all logged entries indeed come from `prospective-parachains` subtraget)

…a=` (#9921)

Follow up on #9920 (but
can be reviewed / merged independently), I'm working on making it easier
to query logs for events, specifically relating to specific parachains.

We also incoherently sometimes use `"para="` and sometimes `"para_id=`",
which also makes Grafana Queries harder to do:

**All queries are done during 1 hour period** (2025-10-03 9:45-10:45
GMT)

## Parachain side:
Query: `{chain="yap-kusama-3392"} |~ "para=""` gives 0 hits
Query: `{chain="yap-kusama-3392"} |~ "para_id=""` gives 12k hits

## Relaychain side:
Query: `{chain="kusama"} |~ "para="` gives 286k hits
Query: `{chain="kusama"} |~ "para_id="` gives 99k hits

# Changes
I've changed so that we always use `para_id=` which is 3 chars longer
but so clearer than `para=` (and with [my
PR](#9920), we saved 4
chars `['I', 'd', '(', ')']`, so this is actually still net -1 char
logged)

All logs seem to come from
[prospective-parachains/src/lib.rs](https://github.com/paritytech/polkadot-sdk/blob/bf235845f9ecb2b84264f255afd7aefdd5ddb603/polkadot/node/core/prospective-parachains/src/lib.rs#L797),
using `para = ?`, which I've now changed to `para_id = ?`

(Grafana (loki) query `{chain="kusama",
subtarget!="prospective-parachains"} |= "para="` yield no results, i.e.
all logged entries indeed come from `prospective-parachains` subtraget)

The `std::fmt::Debug` impl (derived) of
[`Id`](https://github.com/paritytech/polkadot-sdk/blob/32cc5d6163781a077c4bdb2cafdf1a538127ebd5/polkadot/parachain/src/primitives.rs#L176)
results in `"Id(42)"` instead of `"42"`, this causes discrepancies in
logs. Sometimes we log `"para_id=Id(3392)"` but sometimes we log
`"para_id=3392"` (without the `"Id()"`).

This makes e.g. Grafana PromQL queries harder to do, and logs harder to
search in general.

## Example
Seen in e.g.:

### Without `ID(<ID>)`

```
2025-09-22 22:28:06.753 DEBUG tokio-runtime-worker parachain::candidate-backing: Candidate backed candidate_hash=0x0cd77dd25cb61040557bb66df8de5c7b637dff05a671765b40bea7222cfa2854 relay_parent=0x7d380118542b6180127a150a86f144c448982c6af40da1dfb9e3119ad7d4c1ab para_id=3392 traceID=17069631741811285016642302447800179835
```

### With `ID(<ID>)`

```
2025-09-22 22:28:06.342 DEBUG tokio-runtime-worker parachain::collator-protocol::stats: [Relaychain] Collation expired age=3 collation_state="fetched" relay_parent=0x7b394ee6c4fa2a3cec8fa82fa2afe5a933314e6a64e09256d7c8a28086b16acf para_id=Id(3392) head=0x92959b2b5fe8aba268bce48baf8a4e6b952055984015b8c1c7c3142c60e66e31
```

This PR changes the impl of `Debug` to be just `"<ID>"`.

([Discussion on
Matrix](https://matrix.to/#/!oRmZcZCtnViqLdLelR:parity.io/$mTaAp2dRtH5_xUkM-2Bc1NsR-hGEbhV2arGVzuq9g3o?via=parity.io))